峰值利用率80%+，视频云离线转码自研上云TKE实践

刘兆瑞，腾讯云高级研发工程师，负责腾讯明眸极速高清，画质重生等产品。专注于codec优化，画质增强等技术。

背景和问题

随着流量资费的降低和带宽的增加，视频成为人们获取信息越来越重要的方式，随之而来的是云点播、视频处理等视频相关业务的飞速发展，而视频转码平台作为云点播、视频处理的基础产品，面临着高并发、高 SLA、高压缩率等等多样的需求，面临着极大的挑战。

对于一般流程来说，我们面临着下面几个挑战和诉求：

1. 不同的转码产品对核心数的需求不同，比如：极速高清、延时敏感的业务，需要大核心来保证复杂运算的稳定性，普通转码则可以用小核心来替代。分布式转码中的合并和切片服务则对 IO 性能，硬盘大小比较关注。

2. 转码业务对 avx 指令集的利用率很高，因此通用 CPU 算力往往并不会成为瓶颈，avx 指令集的计算频率则成为转码业务的关注重点。而集群内 CPU 型号往往是多样的，因此合理的选择 CPU 型号对于转码业务非常重要，TKE 扩展 pod 时候需要能够选择 CPU 型号。

3. 短期、高并发需求多：客户会用我们的能力实现不同的玩法，比如：客户需要对其全站的视频进行极速高清压缩或者画质增强，这里短期内需要能够获取到巨大的资源，并在使用过后能够快速退回节省成本。

4. 模型、服务迭代快：云服务厂商间的竞争非常激烈，经常会有客户提出新的需求，pod 能够支持快速、无损的更新迭代版本。

容器化 & 全量上云记录

容器化

这里的容器化过程，主要包括对业务的服务流程梳理，整体的发布流程规范化：

业务不同性能机型申请

迁移 TKE 之前，物理机的型号往往是固定的，固定 CPU 核数、内存、硬盘容量的搭配，而这些对于指定业务来说往往会造成资源的浪费，无法充分利用所有的资源。

比如：转码业务关心 CPU 性能，对于内存的利用则很低，而物理机 48C 的机型往往搭配 64G 内存，造成一定程度的内存浪费。

迁移 TKE 之后，根据不同的业务模型场景，可以精确的分配业务所需要的 CPU、内存、硬盘资源，充分利用起每一项资源。

CPU 型号限制

转码业务对 avx 指令集的利用率很高，而很多型号的 CPU 虽然通用计算频率高，但是指令集被限频了，这种型号的 CPU 虽然核数多，但是编码效率很低。因此业务进行 pod 扩展时，希望能够规避剔除掉某些型号的 CPU。

为了解决这一问题，TKE 支持了 CPU 亲和性配置，配置如下：

快速扩缩容

转码业务虽然是离线业务，但是重点客户对 SLA 还是有很高的要求。需要能更快速扩缩容，满足客户动态需求。

面对这种突发的请求，TKE 可以通过动态的扩缩容满足需求，同时业务流量突发结束后，也可以快速缩容来降低使用成本。

当然，动态扩缩容也会带来额外的挑战。对于转码业务来说，很多任务都是长时任务，不能中断的。比如：个100+小时的视频转码，已经转了50小时+，不能因为扩缩容而中断任务，重新转码。针对这种场景，TKE 也给出了很好的解决方案，可以通过删除保护完美支持这一诉求。

业务快速更新上线

云端转码服务多个云上基础产品，大量公司内外客户，需求和发布节奏都很快，每周都会有新的版本升级变更。因此能够支持快速发布，是业务的强诉求。同时，发布不能中断业务正在处理的任务，针对这一情况，TKE支持了原地升级选项，升级 POD 业务代码，不需要销毁重建 runtime 运行中容器，支持服务运行中实现热更新。

lxcfs & 固定 IP 助力任务精准调度

转码的业务与通用的业务请求不同，在开始转码前是无法预知当前转码请求的资源消耗量的。比如：游戏直播视频和课堂教育视频，资源的消耗量会相差一个量级。

因此转码任务的调度是依赖转码机主动上报当前任务数和每个任务的负载情况，由调度根据当前的实际负载情况来分发新的任务请求。

然而，通用的 pod 内进行 ps 等操作获取的是母机的负载信息，而不是当前 pod 的实际负载信息，这样会导致调度失衡。为了解决这一问题，TKE 支持 lxcfs  配置，通过 lxcfs 可以精准获取当前 pod 的实际负载信息。

面对上面的场景，另一个问题是如果每次 POD 重建过程都会重新申请 IP，那无疑会对调度的 IP 管理造成额外的负担。针对这种情况，TKE 也支持了固定 IP，IP 保留等能力。

上线成果

视频云离线转码服务，CPU 平均利用率50%+。峰值利用率80%+。同时，动态的扩缩容和快速上线的支持，都有效的为业务需求和流量突发保障护航。

  往期精选推荐  

点个“在看”每天学习最新技术